It is generally necessary for modem Web-based applications to maintain a “session”. A “session” means a sequence of transactions, i.e., requests and responses sent back and forth between the Web-based application or Web server and the user. This need to maintain a session arises because Web-based applications use the HTTP protocol, which is by itself a stateless protocol, meaning that each request-response pair is independent of previous ones. This session will often be referred to as an “application session” herein.
In order to maintain an application session, some type of “token” or “ticket” must be passed by the Web browser each time a request is sent to the application in order for the application to associate this request with the specific application session. Since the token remains the same in all subsequent client requests, the application identifies all such requests as part of the same application session. A “cookie” is the most commonly used type of token for this purpose, although other alternatives exist, including using a specific URL parameter as the token. In addition to serving as an application session identifier, this token sometimes contains some additional application session information.
In order to authenticate the user, a software component may be implemented which resides between the user and the Web server and authenticates the user at the beginning of each session. Authentication is often accomplished by challenging the user to provide some credentials unknown to other users. These credentials could be in the form of passwords, client certificates, or readouts from some physical devices that the user carries and can be verified at the server side. This authentication component can be implemented as a proxy, filter, or other agent well known to those skilled in the art. For example, a software component residing in front of the Web server and receiving requests on behalf of the server, and eventually passing the requests to the server and the responses from the server back to the client may be implemented. As an additional example, a software component residing on the Web server that interacts with the Web server in order to modify and/or control the request/response data-flow may be implemented.
Like the application as described above, the authentication component must also keep track of the user's session in order to preclude the need to re-authenticate the user every time a request is sent. Being in the middle of the data path between the user and the application, the authentication component could theoretically accomplish this by tracing the application session tracking process, for example, by verifying that the cookie described above continues to be passed to the application. In reality, however, it usually accomplishes this via independent session tracking, using similar mechanisms. For example, a different cookie is issued by the authentication component, which is used either as a session identifier or as an encrypted authentication approval ticket (i.e., presenting this ticket along with a request approves the request). This is described in more detail in the following paragraph. As a result, re-authentication is necessary only when a new session with this authentication component is initiated. For the sake of clarity, this session will be referred to as an “authentication session” herein.
In the case of an authentication session maintained by means of a cookie or token used as a session identifier, the authentication component issues a cookie or other token to the client such as the Web browser upon the user's first request. The user's first request typically does not contain a valid token/cookie. The cookie or token issued by the authentication component contains a random number. The random number should be large enough to prevent “brute force” attacks, which attempt to find the value by guessing, from succeeding within a reasonable amount of time. The random number is used internally at the authentication component to identify an entry in a session table using a hashing algorithm. This session table contains all active sessions currently being maintained by the authentication component. In the case of an authentication session maintained by means of an encrypted authentication approval ticket, or encrypted token/cookie, whatever information would be stored in the session table described above is instead encrypted in the cookie that is sent back and forth between the browser and the authentication component together with each request and response. The authentication component uses a cryptographic key, which is unknown outside the scope of the authentication component, and it adds some fixed “salt” value to the information encrypted, which is used to verify a legitimate cookie upon decryption.
An issue exists with regards to termination of the authentication session. Once a user is authenticated at a terminal, it is assumed that all subsequent requests that that terminal issues come from that authenticated user. Accordingly, it is critical that when the user finishes his interaction with the application, the authentication session terminates, so that a new user at that terminal will not be mistakenly assumed to be already authenticated. This is particularly important when the user is logging in from public spaces such as Internet cafes, airports, etc. Since there is no standard method of logging off from a Web-based application, most authentication mechanisms utilize some form of a “time-out” mechanism, whereby if a user does not interact with the application for a certain amount of time, for example, 10 minutes, the authentication session expires. Alternatively, some authentication mechanisms implement a fixed time-out, which allows the session to stay alive for a certain amount of time, regardless of user activity. However, such mechanisms are inadequate in public spaces where a stranger can take control of the browser a moment after a legitimate user has ostensibly signed off. This problem is exacerbated where public Internet access facilities “lock down” their browsers (i.e., the browser cannot be closed), since in that case the user cannot even terminate the session by closing the browser (which would typically discard its cookies when closed).
Moreover, despite the fact that an application may contain some type of log-off button or URL which is intended to terminate the application session (not to be confused with the authentication session), such termination typically would have no effect on the authentication mechanism because existing authentication mechanisms are unaware of the application's log-off mechanism, and therefore the authentication mechanism would not terminate the authentication session. As a result, the next person using the same browser could be implicitly authenticated by the authentication component since a legitimate cookie would be sent to the authentication component. This would allow a malicious user to interact with the supposedly protected application (even though engaging possibly in a new application session) without first authenticating his identity via the authentication component's authentication mechanism. Thus, while the application may have its own authentication feature (e.g., a user name and password) which would provide some level of protection against this malicious user, the superior authentication provided by the authentication component's authentication mechanism would be bypassed. In the case of an application that provides HTTP Basic Authentication, the potential to bypass the authentication component's authentication mechanism would leave the application particularly vulnerable, since there exists an inherent vulnerability in HTTP Basic Authentication resulting from the fact that the Web browser saves the user names and passwords of previous users who have accessed a site.
Therefore, it is highly desirable to have a system and method for allowing an immediate authentication session termination when the legitimate user signs off. In addition, it is also desirable that this system and method allow immediate session termination even if the application itself does not inherently support a sign-off feature.